An ITMS-91061: Missing privacy manifest rejection email looks as follows: ITMS-91061: Missing privacy manifest- Your app includes "<path/to/SDK>", which includes , an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting February 12, 2025, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. Glossary ITMS-91061: Missing privacy manifest: An email that includes the name and path of privacy-impacting SDK(s) with no privacy manifest files in your app bundle. For more information, see https://developer.apple.com/support/third-party-SDK-requirements. : The specified privacy-impacting SDK that doesn't include a privacy manifest file. If you are the developer of the rejected app, gather the name of the SDK from the email you received from Apple, then contact the SDK's provider for an updated version that includes a valid privacy manifest. After receiving an updated version of the SDK, verify the SDK includes a valid privacy manifest file at the expected location. For more information, see Adding a privacy manifest to your app or third-party SDK. If your app includes a privacy manifest file, make sure the file only describes the privacy practices of your app. Do not add the privacy practices of the SDK to your app's privacy manifest. If the email lists multiple SDKs, repeat the above process for all of them. If you are the developer of an SDK listed in the email, publish an updated version of your SDK that includes a privacy manifest file with valid keys and values. Every privacy-impacting SDK must contain a privacy manifest file that only describes its privacy practices. To learn how to add a valid privacy manifest to your SDK, see the Additional resources section below. Additional resources Privacy manifest files Describing data use in privacy manifests Describing use of required reason API Adding a privacy manifest to your app or third-party SDK TN3182: Adding privacy tracking keys to your privacy manifest TN3183: Adding required reason API entries to your privacy manifest TN3184: Adding data collection details to your privacy manifest TN3181: Debugging an invalid privacy manifest

In this post, we'll share tips to help you submit apps that deliver original ideas to your users. When working on your app, focus on creating interesting, unique experiences that aren't already available. Apps that actively try to copy other apps won't pass review, and accounts that repeatedly submit copycat apps or attempt to impersonate a service will be closed. The rules that prevent copycat and impersonator apps from being distributed on the App Store are described in App Review Guideline 4.1: 4.1 Copycats (a) Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers. (b) Submitting apps which impersonate other apps or services is considered a violation of the Developer Code of Conduct and may result in removal from the Apple Developer Program.(c) You cannot use another developer’s icon, brand, or product name in your app’s icon or name, without approval from the developer. These requirements help make the App Store both a safe place for people to discover apps and a platform for all developers to be successful. Best Practices Here are three best practices that will help you submit apps that follow App Review Guideline 4.1: 1. Submit apps with unique content and features. People want apps that provide unique experiences. Find areas that aren't currently being served and build compelling apps for those audiences. Do: Create apps that provide a new experience or a unique spin on an existing concept. Design original, delightful interfaces that elegantly meet your user's needs. Don't: Don’t imitate the features and functionality of other apps. Don’t copy the look and feel of other apps, such as using an identical user interface design. 2. Make sure App Store metadata only contains relevant information and content you either own or have permission to use. The metadata provided in App Store Connect is used to populate your app's product page on the App Store. People rely on this metadata to learn about your app and what it has to offer. Leveraging the popularity of another brand or app, either by including irrelevant references or protected content, is misleading and won't help your app succeed. Do: Use engaging, descriptive language to describe your unique app. Create original content that best represents your app, such as screenshots showing the actual app in use. Don't: Don't use protected material you do not have the necessary permission to use, such as app icons that are similar to icons of a popular app. Don’t include irrelevant references, such as popular app names or trademarked terms, in any metadata fields. 3. Provide information that is authentic and verifiable. People want to know the developers behind their favorite apps are who they say they are. It's important to continually review and provide up-to-date information, including the developer or company name listed on your Apple Developer Program account, the Support URL listed on your app's product page, and other helpful information. This will enable your users to contact you when they need help and it will also hinder people who may try to impersonate you, your app, or your service. Do: Make sure all information, resources, and documentation related to your account and apps are current and accurate. Don't: Don’t provide inaccurate information or resources, such as directing people to outdated support pages. Don’t provide fraudulent documentation. Accounts that submit fraudulent documentation will be removed from the Apple Developer Program. Support Incorporating these best practices into your app's development will help you submit apps that follow App Review Guideline 4.1. If you need additional assistance, consider taking advantage of one of the following support options available from App Review: If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. Request an App Review Appointment to discuss the results of our review. Appointments are subject to availability, and take place during local business hours in your region on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board. Resources Learn about foundational design principles from Apple designers and the developer community. Learn how to create engaging App Store product pages. Note that apps that violate intellectual property rights are subject to removal through the App Store Content Dispute process. If you believe an app on the App Store violates your intellectual property rights, you can submit a claim.

Hello App review Team, Our app has been submitted for up to a week now. Submission id - 8b32ad4d-9912-4f25-837c-13b15323a258. Kindly review. Thank you

Hello, I'm posting again — and unfortunately, I already know how this thread is going to go. My app (ID: 6756186616) has now been stuck in "In Review" for 80 days. To save everyone time, here is the reply I expect to receive within a day or two, copy-pasted from the response on my last thread: "Thank you for your post. We're investigating and The App Review team will contact you in App Store Connect to provide further assistance. If you continue to experience issues during review, please contact us." Nothing actually happened after that reply last time. No follow-up in App Store Connect. No further communication. Just silence. When I escalated to Developer Support (case #20000111565861), I was told explicitly that Developer Support has no way to reach the App Review team and no authority to intervene on submissions stuck in review. So Developer Support points back to App Review, and the standard forum reply points back to "contact us" — which loops back to Developer Support. This is a closed loop that doesn't actually resolve anything for an independent developer. Concrete questions: Is there any real escalation path that doesn't end in an automated reply? Why has a submission been "In Review" for 80 days with zero communication? What should a solo developer do when both Developer Support and the forum response are dead ends? I'm not asking for special treatment. I'm asking for the review to actually move — in either direction. A rejection with feedback would be infinitely more useful than 80 days of silence. Thank you.

Hi, My iOS app, "GNYS" (Apple ID 6761986315) was submitted on 14 April 2026 and has had the status, "Waiting for Review" since then - now for 24 days. This is a first submission. I previously contacted Apple Support but haven’t received a clear explanation or timeline. I’d really appreciate it if the App Review team could look into this or advise on whether any additional information is needed from my side. Thank you.

can someone please help with the review ? Hi everyone, I submitted my app ZEROCAUGE PRO on April 21st. It has been 16 days and the status is still "Waiting for Review." This is impacting real users and a live business. Paying coaches and athletes are waiting daily to use this platform. Is anyone else experiencing this? And has anyone found a way to actually get Apple to respond? — James | CreateTitan (ZEROCAUGE PRO)

I have a new desktop software submission for macOS. It has to do with designs. The application serves two different roles of users. If they select the design leader role, they will get to create design projects. If they select the design follower role, they will not be able to create design projects. But they will get to view ones from the design leader. When the application starts up, it will prompt the user to select a role. If they click on the role acceptance button, they will be prompted for confirmation. The application also comes with a built-in tutorial that explains that design followers will not be able to create design projects. I knew the reviewer will play dumb and reject this software submission after selecting the follower role by claiming that he or she cannot create a design project. So I've given repeated warnings under Apple Review Information, telling them to select the design admin role if they want to test-create design projects. But they still fail and play dumb by starting that he or she cannot create one. The screenshot the reviewer provided me with indicates that he or she has indeed selected the user role. What's the point of this playing-dumb cycle of stupidity? No matter how many filters I place so that they won't select a wrong role, reviewers still manage to play dumb and fail. I already waited for 5 1/2 days for this new submission to be reviewed. Why do they reject every single new submission I make? Reviewers are wrong 6 or 7 out of 10 times. What a waste of time and resources... I think I'm infected with the mad cow disease.

Hello, I would like to ask for guidance regarding the termination of my Apple Developer Program account. The account had been active for over 15 years and was my primary source of income. In November 2025, I received a notice stating: You provided fraudulent and/or false account information, documentation, or otherwise falsely represented yourself or your submitted app to Apple either during the account enrollment process or after the account was created. I take this matter very seriously. I have always used my real identity and valid documentation, and I have never intended to misrepresent myself or my apps in any way. I am fully willing to provide any documents again to reconfirm my identity if required. Over the past several months, I submitted multiple appeals in an effort to better understand the reason for this determination. However, I have only received general responses without specific details or actionable guidance. Six months later, I received a final Notice of Termination. I fully respect Apple’s policies and the need to maintain trust and integrity within the platform. At the same time, it’s been hard to understand what exactly caused this issue or what could have been fixed earlier. If anyone from the App Review Team or other Apple representatives can provide general guidance on (I am posting from the same account/email that was originally used to enroll in the Apple Developer Program.): what types of situations may lead to this kind of determination, or whether there are any possible steps to clarify or resolve identity-related concerns I would be very grateful.

Our app is stuck with "Waiting for review" for 4 days so far after rejection. We have to resubmit it yesterday, but more than 24 hours have passed and still nothing. Submission ID: 05e2667a-5641-4fbf-af44-aff94b03ae11

Hi to you all, I have a problem with setting up a subscription for an app for the first time. I keep getting a rejection with the message under Guideline 2.1(b) that “one or more of the In-App Purchase products have not been submitted for review.” I don’t know what to add anymore. I only have two monthly subscriptions. I set them up and selected them in the version description and submitted the package. There‘a not more information what exactly is missing. The only other information is the following: “Note you must provide an App Review screenshot in App Store Connect in order to submit In-App Purchases for review.” I’d be glad to get some advice.. Thank you in advance for your help!!

I’m working on an iOS app and need help with ASO to find the best keywords for title, subtitle, description, and keyword field. Can anyone suggest free tools that show keyword volume, difficulty, and competitor keywords?

I launched my app on the App Store and Google Play about two months ago and despite improving the icon and screenshots I have only reached around 40 downloads which makes me believe ASO is my main challenge. I started using ASO tools like TryAstro and AppTweak but the keyword metrics such as volume 39 and difficulty 0 are confusing so I would appreciate guidance on interpreting this data and on effective ASO strategies for a new app with minimal downloads or ratings.

I've been stuck on Guideline 2.3 for two weeks now and I'm running out of ideas. My app is iPhone-only (UIDeviceFamily = [1]) and has been on the App Store since January. Version 2.1.9 passed review fine. The only change in 2.1.10 is adding two DeviceActivity extensions — a DeviceActivityMonitor and a DeviceActivityReport — for screen time-based stress detection. Every build since then gets rejected with the same message: "The UIRequiredDeviceCapabilities key in the Info.plist is set up in such a way that the app will not install on the device used in review." Review devices: iPhone 14 Pro, iPhone 17 Pro Max, iPad Air M3. Here's what I've tried across 13+ submissions: UIRequiredDeviceCapabilities as ["arm64"] (array) — rejected Empty array [] — rejected Removed the key entirely — upload validation fails, Xcode re-injects arm64 anyway Post-build script to force ["arm64"] — rejected Dictionary format {"arm64": true} — rejected Added com.apple.developer.family-controls to extension entitlements — rejected Enabled Family Controls (Distribution) on extension bundle IDs — rejected Fixed CFBundleVersion mismatch between host app and extensions — rejected Set TARGETED_DEVICE_FAMILY=1 on all targets including extensions — rejected Tried GENERATE_INFOPLIST_FILE=YES with minimal plists — rejected Tried ExtensionKit type for the report extension — rejected In the exported IPA, every target has UIRequiredDeviceCapabilities = ["arm64"] and UIDeviceFamily = [1]. The entitlements, provisioning profiles, and code signing all look correct. arm64 is supported on every review device they listed. The previous version (2.1.9) without DeviceActivity extensions passes review with the exact same UIRequiredDeviceCapabilities and signing configuration. Has anyone shipped an app with DeviceActivityMonitor + DeviceActivityReport extensions successfully? Is there something specific about these extension types that affects device capability validation? Or is there a known issue with the review system and FamilyControls extensions? I've replied to the review team multiple times asking which specific capability is causing the failure, but the response is always the same generic template. Any guidance would be really appreciated — I'm completely blocked on shipping this update.

I’m building a macOS app with a MailKit extension. The containing app needs to show whether the Mail extension is enabled and actually being invoked. Currently the extension writes a “last seen” timestamp to app group defaults when Mail invokes it. The containing app reads that timestamp and shows a waiting/active state. During App Review, this behaviour was challenged: enabling the MailKit extension in Mail Settings does not immediately change the state reported in the containing app. The extension is only invoked when Mail receives or reloads messages, so the main app cannot confirm it is active at the moment the user enables it. The review challenge is that App Review may enable the extension, open Mail, select existing messages, and still see the containing app stuck in a waiting state. From what I can tell, selecting old messages does not reliably cause Mail to invoke the extension. I looked for a direct API like: let isEnabled = try await MEExtensionManager.shared().isEnabled But I do not see any public MailKit API that reports whether the extension is enabled in Mail Settings. MEExtensionManager seems limited to reload-style APIs such as reloadVisibleMessages. Questions: Is there a supported way to check whether a MailKit extension is enabled? Is “first extension invocation” the expected confirmation signal? Can reloadVisibleMessages be relied on during review, or can Mail skip/throttle old messages? Is the right App Review instruction: enable the extension, quit/reopen Mail if needed, then send a new test email? If possible, I want the app to report that the extension has been enabled as soon as the user turns it on in Mail Settings, even if Mail has not invoked the extension yet, but I do not see a public API that exposes that enabled state.

I’m running into an App Store Connect issue and I’m trying to figure out whether this is a build configuration problem on my side or a backend issue in App Store Connect. When I try to save my app version after selecting a build, App Store Connect fails and DevTools shows this request failing: PATCH /iris/v1/appStoreVersions/ with a 409 Conflict. The response body is: Json { "errors": [ { "id": "af484f56-8f7d-4338-a04a-2aeda858ace1", "status": "409", "code": "ENTITY_ERROR.RELATIONSHIP.INVALID", "title": "The provided entity includes a relationship with an invalid value", "detail": "The specified pre-release build could not be added.", "source": { "pointer": "/data/relationships/build" } } ] } A few details: The issue seems to happen with all uploaded builds, not just one The builds finish uploading and appear in App Store Connect I’ve already checked and corrected my version/build number setup I created a fresh Release archive I uploaded a new build I removed the previously attached build and tried attaching the new one App Store Connect still refuses to save the version once a build is selected I’ve already verified that the app version and build number in the project appear to be set correctly. At this point I’m trying to understand: Any suggestions on specific things to check would be appreciated. Thanks.

Hi all, We are developing an iOS app that includes private user-to-user chats, commercial offer details with monetary value, and customer identification data. In line with OWASP MASVS-PLATFORM-3 requirements regarding unintentional sensitive data exposure, we need to protect these specific screens from screenshots and screen recording. We have carefully reviewed the relevant App Review Guidelines (2.5.1 on public APIs, 2.5.2 on self-contained bundles, 5.1.1 on privacy) and the related Human Interface Guidelines. From this analysis we have observed the following: iOS does not expose a public API to globally disable screen capture (no direct equivalent of Android's FLAG_SECURE). The SwiftUI .privacySensitive() modifier is effective for Lock Screen widgets and Always-On Display, but it does not appear to prevent screenshots or screen recording of an app's main UI while in the foreground. A number of widely distributed App Store apps (banking, authenticator, secure messaging) implement some form of screenshot protection on sensitive screens. Several established open-source libraries leverage the system behavior of UITextField with isSecureTextEntry as a wrapping container for arbitrary views, in order to achieve pixel-level protection for sensitive content. We would appreciate clarification on the following points: For privacy-driven protection of sensitive screens (private chats, customer data, monetized offers), is there an officially recommended approach we may have missed? Are there public APIs intended specifically for this use case beyond .privacySensitive()? Is the practice of leveraging UITextField with isSecureTextEntry as a wrapping container for arbitrary views considered an acceptable use of public APIs under Guideline 2.5.1, or does it carry App Review risk? Are there official recommendations or documentation for apps handling sensitive personal data that wish to align with industry standards such as OWASP MASVS-PLATFORM-3 for screenshot and screen recording leakage prevention? The intended use is strictly limited to a small number of screens marked as containing sensitive data (private messages, deal details, customer information). The protection would be selective and clearly communicated to the user via in-app messaging, not global to the app. Thanks in advance for any clarification, including pointers to existing documentation or threads we may have missed. Deployment target: iOS 15+

We have been waiting for the App Review process to complete for almost 2 weeks already. The review process appears to be completely stalled.

I'd appreciate input from anyone who has shipped a multiplatform productivity service (web + iOS + Android) where the iOS app is free and the website handles subscriptions. We just went through several review cycles on this and want to make sure we end up on the right pattern long-term. The setup Cross-platform productivity SaaS. Users sign up and subscribe on the web. The iOS app is fully free. No IAP, no upgrade UI, no pricing screens, no paywalls, no plan-tier badging. iOS exists primarily for capabilities a browser/PWA cannot deliver on iOS: native geofencing and native phone-call detection, plus on-the-go time capture. The same account a user has on the web is the account they sign into on iOS. The question For a multiplatform service like this — what's the safest, App-Review-defensible pattern for the iOS app's relationship to the user's web subscription tier? There appear to be two patterns in the wild: Tier-identical iOS — every iOS user, regardless of their web plan, sees an identical feature set on iOS. The iOS app surfaces nothing tier-specific. Web subscribers don't gain anything on iOS for being subscribers. Tier-aware iOS under 3.1.3(b) — Free users see a base feature set; users who already paid on the web see additional features mirroring their web account, framed under Multiplatform Services. What we learned Pattern 2 reads naturally from 3.1.3(b)'s text about apps "operating across multiple platforms" letting users "access content … acquired … on … your web site." We initially built and submitted with pattern 2. The piece we underweighted is the "also" in 3.1.3(b): "provided those items are also available as in-app purchases within the app." App Review's reading is that 3.1.3(b) only attaches if IAP is also offered in the iOS app for those items. If IAP is not offered, "Pro features visible to paid web users on iOS" is read as 3.1.1 (paid digital content accessed in-app without IAP), regardless of how the entitlement was granted. We resolved it by switching to pattern 1 — tier-identical iOS — which made the question moot. The product cost of pattern 1 Worth flagging for anyone weighing this themselves: pattern 1 (tier-identical iOS) creates a real and visible feature divergence between iOS on one side, and Android + web on the other. On Android we surface the user's paid-tier features just like the web does — there's no equivalent guideline forcing tier-uniformity on the Play Store side. So a Pro user on the same account sees a meaningfully different app on iOS than on their other devices. That's the trade we accepted to be unambiguously compliant with 3.1.1, but it is a trade — not a free move. Users notice. Support tickets will reflect it. For an internal stakeholder asking "why is iOS missing X," the honest answer is "App Store rules around paid digital content, with no IAP path that fits our pricing model." Specific things I'd love input on For other multiplatform services without IAP — has anyone defensibly shipped pattern 2 in the last ~12 months? If so, what was the framing? Is there a documented carve-out under 3.1.3(b) for genuinely free iOS apps, or has the "also available as IAP" language been read strictly across the board? For apps that took pattern 1 (tier-identical iOS): did you find any side-effects (e.g. App Store reviewers questioning the value of an iOS app that doesn't differentiate by plan)? For teams who took pattern 1: how did you communicate the iOS / Android feature gap to users? In-app message, FAQ, just leave it implicit? Are there cases where a phone call from App Review (offered in the rejection email) clarified this faster than the written back-and-forth? What I think the takeaway is, for posterity For a free iOS app fronting a cross-platform paid service, tier-identical iOS is the unambiguous safe harbour today. 3.1.3(b) appears to require IAP to be offered before it can be cited as cover for tier-aware behaviour, even if the user paid elsewhere. If anyone has a recent counter-example I'd genuinely like to see it — it would be useful for the next thread someone Googles. Thanks in advance.

Issue Description We noticed the app shares a similar binary, metadata, and/or concept as apps submitted to the App Store by other developers, with only minor differences. Next Steps Since we do not accept spam apps on the App Store, we encourage you to review the app concept and submit a unique app with distinct content and functionality. Resources Some factors that contribute to a spam rejection may include: Submitting an app with the same source code or assets as other apps already submitted to the App Store Creating and submitting multiple similar apps using a repackaged app template Purchasing an app template with problematic code from a third party Submitting several similar apps across multiple accounts Learn more about our requirements to prevent spam in guideline 4.3.

Our Flutter app has been rejected by App Review 4 times with this description: "Login screen cleared the email and password fields when we attempted to enter the demo account details, preventing us from logging in." Review environment: Device: iPad Air 11-inch (M3) OS: iPadOS 26.4.2 Flutter version: 3.41.4 State management: GetX We cannot reproduce this on: Real iPhone (iOS 18.x) — works fine iPad simulator (iPadOS 26.3.1) — works fine Our TextEditingControllers are created inside a GetX controller, not inside build(), so they survive widget rebuilds. Questions: Has anyone seen text fields clearing or not retaining input specifically on iPad with iPadOS 26? Are there any known Flutter issues with text input on iPadOS 26 that could cause this? Is there anything different about how iPad handles text input vs iPhone that we should be aware of? Any help appreciated — this is blocking our App Store approval.

My app has been rejected twice, noted that the app is a financial app (banking app). The latest reply from Apple is provided below. "Issue Description The app provides loan services but the domains listed on the app's Product Pages are not clearly under your control or ownership. Since users may use these domains to contact you to request support, the domains used on the Product Page for loan apps must be under your control or ownership. Next Steps Update the Product Page metadata in App Store Connect to only include domains that you both own and are used as email domains for Apple Accounts registered to your developer account. You can review the email domains and Apple Accounts registered to your developer account in the Users and Access section of App Store Connect. Account Holder and Admin users should use emails with domains that identify the company providing loan services. Please note that apps used for financial trading, investing, or money management should be submitted by the financial institution performing such services, as required by App Review Guideline 3.2.1(viii)." Any suggestion?

We've a game that the first version has published 45 days again with a quick review and direct approve. After that initial version, we've made some big updates and additions as well as some bug fixes to get ready to officially publish our game, and market it. However, with my first update, it waited in the review queue for 2 weeks, which I then cancelled, make some bug fixes, and sent to review again since I heard that this can fix the process sometimes. Even after that, we've been waiting for 3 weeks and still no updates. I've also applied for Expedited Review since this is getting urgent after waiting more than a month. I hope someone from Apple Support team will see this and help me with the issue.